\chapter{TLS/SSL}

Algumas informações sigilosas não podem correr livremente na internet, há um alto risco de interceptação, existe a chance de alguém se passar pelo destinatário e ainda há a chance da mensagem ser alterada em trânsito. Para resolver todos esses problemas e permitir um fluxo de informações privadas e autênticas usa-se de criptografia e do protocolo TLS (\emph{Transport Layer Security}).

O protocolo TLS é sucessor do SSL(\emph{Secure Sockets Layer}) e serve justamente para garantir integridade, sigilo e autenticidade de pacotes enviados pela internet~\cite{RFCSSL1}~\cite{RFCSSL2}. O protocolo não está definido como uma camada da pilha TCP/IP ou do modelo OSI, mas age como uma camada abstrata entre a camada de aplicação e a camada de transporte~\cite{figSSL}. O protocolo funciona em cima de fluxos TCP, pois há garantia de conexão entre as duas partes.

\begin{figure}[H]
\centerline{\includegraphics[scale=0.7]{figuras/sslPilha.png}}
\caption{Esquema de localização do protocolo TLS/SSL na pilha TCP/IP ~\cite{figSSL}. }
\label{fig:pilhaSSL}
\end{figure}

O TLS e o SSL são protocolos criptográficos que usam criptografia assimétrica e simétrica, além de certificados, para garantir uma conexão segura sem extravio de informação~\cite{RFCSSL1}~\cite{RFCSSL2}. O funcionamento do protocolo TLS/SSL diz que primeiramente o cliente deve requisitar ao servidor desejado uma conexão segura TLS/SSL, mas alguns servidores costumam induzir o cliente a tal conexão segura. O protocolo começa com o cliente requisitando a conexão segura através de um \emph{handshake}, que seria um acordo entre as partes de como a conexão irá acontecer. É durante o \emph{handshake} que ocorrem as verificações dos certificados para garantir que ambas as partes são quem dizem ser. 

A conexão funciona em cima de uma outra conexão TCP, e depois de feito o \emph{handshake} TLS/SSL todos os dados transmitidos entre as duas partes serão cifrados de tal forma que apenas as duas partes conheçam o conteúdo transmitido, até que a conexão seja encerrada.

\section{Criptografia simétrica e assimétrica}
Para entender o funcionamento do protocolo TLS é necessário um conhecimento prévio de criptografia, pois o mesmo usa amplamente de criptografia simétrica e assimétrica.

Criptografia assimétrica ou criptografia de chave pública é um tipo de criptografia onde é usado um par de chaves (diferentes entre si) para cifrar e decifrar uma mensagem, para que a mesma seja transmitida de forma segura através de um canal inseguro. Inicialmente uma organização que queira usar criptografia assimétrica pede um par de chaves a uma autoridade certificadora, essa autoridade irá guardar a chave pública da organização e toda vez que um novo usuário quiser se comunicar, a autoridade certificadora irá confirmar que tal chave é de fato a chave pública correta da organização.

A chave pública serve para cifrar a mensagem, que só poderá ser decifrada por quem possuir a chave privada (a organização). Por mais que todos os usuários conhecam a chave pública, apenas a organização sabe decifrar, logo, usuários usando de criptografia assimétrica podem ter certeza que estão se comunicando verdadeiramente com a organização desejada (garantido pela autoridade certificadora).

Em algoritmos cujo o processo de cifragem e decifragem coincidem, como o RSA, as mensagens também podem ser cifradas com a chave privada e decifradas com chave pública (processo contrário). Esse processo permite que a identidade do usuário também possa ser autenticada quando usado corretamente~\cite{assimetrica}.

A criptografia simétrica é mais simples, nela é usado apenas uma chave para cifrar e decifrar mensagens. No entanto, ambas as partes devem conhecer a chave préviamente, que deve ser transmitida através de um canal seguro~\cite{assimetrica}.

\begin{figure}[H]
\centerline{\includegraphics[scale=1]{figuras/assimetria.png}}
\caption{Figura com o diagrama de uso de criptografia de chaves assimétricas~\cite{figassimetrica}(adaptada para o português). }
\label{fig:public}
\end{figure}

\section{Certificados}
Uma característica do TLS/SSL é garantir autênticidade das partes envolvidas. Para isso, o protocolo exige um certificado por parte do servidor usando TLS e, opcionalmente, do cliente. Um certificado é um arquivo contendo uma chave pública, dados da organização dona do certificado, dados da autoridade certificadora e informações sobre o tipo de criptografia usada. 

O certificado é enviado a quem deseja se conectar seguramente ao servidor, o cliente irá verificar a veracidade desse certificado com uma autoridade certificadora. Depois o cliente trocará algum tipo de mensagem cifrada com o servidor, pois apenas quem possuir a chave privada poderá entender aquela mensagem, logo se o servidor responder corretamente ele é dono da chave privada corrreta. Se o servidor é de fato dono da chave privada, pode-se garantir a sua identidade baseado na autoridade certificadora.

Autoridades certificadoras costumam cobrar pelos seu serviços, por isso acabaram por se popularizar certificados auto assinados. Esses certificados não possuem nenhuma autoridade certificadora, um cliente deve confiar cegamente nesse certificado para proceder com a conexão. Na figura ~\ref{fig:selfcertificate} podemos ver um certificado auto assinado, no topo da figura há um aviso aos usuários de que o certificado não possue uma autoridade certificadora e que o usuário está confiando de livre e espontânea vontade naquele certificado.

\begin{figure}[H]
\centerline{\includegraphics[scale=1]{figuras/selfcertificate.png}}
\caption{Exemplo de um certificado auto assinado e de campos de informação dos certificados. }
\label{fig:selfcertificate}
\end{figure}

\section{Funções de resumo}
Outra característica do protocolo TLS é garantir a integridade das mensagens, garantir que as mensagens enviadas sejam iguais as mensagens recebidas. Com essa finalidade usam-se funções de resumo (no inglês \emph{hash}), essas funções recebem como entrada uma grande quantidade de bytes e retornam uma quantidade menor e diferente para cada entrada. As funções de \emph{hash} retornam uma quantidade de bytes que equivale a uma \lq{}identidade\rq{}  da entrada, mas de menor tamanho. Boas funções de \emph{hash} tem uma saida diferente para cada entrada e é impossível obter a mensagem original a partir de sua saída.

Existem várias funcões de resumo criptográfico, no protocolo TLS são usadas para garantir que a mensagem esteja íntegra. Cada mensagem é concatenada com seu \emph{hash}, assim, quem recebe a mensagem tira o seu próprio \emph{hash} e compara com o valor concatenado na mensagem. Caso os valores coincidam, a mensagem está correta, caso haja uma divergência, houve modificações ou irregularidades na mensagem.

\section{\emph{Handshake} TLS/SSL}
Uma vez que o \emph{handshake} seja concluído toda troca de informação será criptografada e o \emph{handshake} é que define como isso será feito~\cite{RFCSSL1}~\cite{RFCSSL2}. O processo de \emph{handshake} começa sempre pelo cliente, esse enviará uma mensagem no formato TLS informando que quer se conectar seguramente com o servidor. A primeira mensagem é denominada \emph{client hello}, ela contêm até qual versão o cliente suporta o TLS/SSL, uma identidade de sessão (caso esteja retomando uma outra conexão), bytes aleatórios, um conjunto de combinações de cifras e \emph{hashs} disponíveis e um conjunto de métodos de compressão. Mais detalhes podem ser observados na figura ~\ref{fig:clienthello} abaixo.

\begin{figure}[H]
\centerline{\includegraphics[scale=1]{figuras/clienthello.png}}
\caption{Exemplo de \emph{client hello}, pode-se observar que o campo de sessão está vazio pois é uma nova sessão.}
\label{fig:clienthello}
\end{figure}

No \emph{client hello} são enviados um conjunto de opções de cifras, cada uma dessas opções de cifras é denominada uma \emph{cipher suite}. Cada \emph{cipher suite} diz como será feita a troca de chaves entre o cliente e o servidor, qual será o método de cifragem e qual será a função de resumo usada~\cite{figSSL}.

\begin{table}[H]
\caption{Exemplos de \emph{cipher suites} ~\cite{cipher}.}
\begin{tabular}{|l|p{5cm}|}
\hline
Cipher Suite	&Comentário	\\
\hline
TLS\underline{ }RSA\underline{ }WITH\underline{ }RC4\underline{ }128\underline{ }MD5	&Essa \emph{suite} usa RSA para negociar as chaves, usa RC4 como método de cifra e a função de \emph{hash} MD5.	\\ \hline
TLS\underline{ }RSA\underline{ }WITH\underline{ }RC4\underline{ }128\underline{ }SHA	&Essa \emph{suite} é similar a primeira mas usa como \emph{hash} a função SHA	\\ \hline
TLS\underline{ }RSA\underline{ }WITH\underline{ }3DES\underline{ }EDE\underline{ }CBC\underline{ }SHA	& 	\\ \hline
TLS\underline{ }DHE\underline{ }DSS\underline{ }WITH\underline{ }3DES\underline{ }EDE\underline{ }CBC\underline{ }SHA	&Essa \emph{suite} usa o protocolo Diffie \& Hellman  efêmero para troca de chaves diferente das outras.	\\ \hline
TLS\underline{ }RSA\underline{ }WITH\underline{ }DES\underline{ }CBC\underline{ }SHA	& 	\\ \hline
TLS\underline{ }DHE\underline{ }DSS\underline{ }WITH\underline{ }DES\underline{ }CBC\underline{ }SHA	& 	\\ \hline
TLS\underline{ }RSA\underline{ }EXPORT1024\underline{ }WITH\underline{ }RC4\underline{ }56\underline{ }SHA	& 	\\ \hline
TLS\underline{ }RSA\underline{ }EXPORT1024\underline{ }WITH\underline{ }DES\underline{ }CBC\underline{ }SHA	& 	\\ \hline
TLS\underline{ }DHE\underline{ }DSS\underline{ }EXPORT1024\underline{ }WITH\underline{ }DES\underline{ }CBC\underline{ }SHA	& 	\\ \hline
TLS\underline{ }RSA\underline{ }EXPORT\underline{ }WITH\underline{ }RC4\underline{ }40\underline{ }MD5	& 	\\ \hline
TLS\underline{ }RSA\underline{ }EXPORT\underline{ }WITH\underline{ }RC2\underline{ }CBC\underline{ }40\underline{ }MD5	& 	\\ \hline
TLS\underline{ }RSA\underline{ }WITH\underline{ }NULL\underline{ }MD5	& 	\\ \hline
TLS\underline{ }RSA\underline{ }WITH\underline{ }NULL\underline{ }SHA	& 	\\

\hline
\end{tabular}
\end{table}

As opções de compressão no final do \emph{client hello}, figura ~\ref{fig:clienthello} são raramente usadas.

Depois do cliente mandar o \emph{client hello} com as \emph{cipher suites}, o servidor responde com um \emph{server hello}, esse pacote contém qual versão do TLS o servidor irá usar, junto com a \emph{cipher suite} escolhida, uma identidade de sessão, o método de compressão escolhido e bytes aleatórios.


\begin{figure}[H]
\centerline{\includegraphics[scale=1]{figuras/serverhello.png}}
\caption{Exemplo de \emph{server hello}.}
\label{fig:serverhello}
\end{figure}

Junto com o \emph{server hello} o servidor também manda uma mensagem com o seu certificado e uma mensagem opcional (\emph{server key exchange}) usada somente em protocolos de troca de chave Diffie \& Hellman (DH e DHE). Para finalizar, o servidor também manda um \emph{server hello done} que apenas serve para simbolizar o fim da sua ação. No geral, a mensagem enviada pelo servidor possue o \emph{server hello}, o certificado e o \emph{server hello done} todos juntos, como na figura ~\ref{fig:ser}.

\begin{figure}[H]
\centerline{\includegraphics[scale=1]{figuras/serverhellodone.png}}
\caption{Exemplo completo, com todas as mensagens necessárias na resposta do servidor.}
\label{fig:ser}
\end{figure}

Finalizando o \emph{handshake} o cliente responde com três mensagens, um \emph{client key exchange}, um \emph{change cipher spec} e um \emph{encrypted handshake message}.

O \emph{client key exchange} serve para terminar a negociação das chaves, no RSA é enviado um segredo com a chave que somente o servidor poderá decifrar, no Diffie \& Hellman é enviado uma chave pública que será usada pelo servidor para computar a chave da sessão, detalhes mais específicos serão mostrados em subseções futuras.

O \emph{change cipher spec} é apenas um byte dizendo que todo o fluxo de mensagem a partir dele será cifrado. E por último, o \emph{encrypted handshake message} é o \emph{hash} de todo o processo de \emph{handshake} já cifrado, essa mensagem será decifrada pelo servidor e o seu \emph{hash} será conferido, em caso positivo o servidor responde, também, com um \emph{change cipher spec} e um \emph{encrypted handshake message}. Feito todo esse processo, o \emph{handshake} está completo e todo tráfego entre cliente e servidor será cifrado garantindo confidencialidade e integridade(\emph{hash}).


\begin{figure}[H]
\centerline{\includegraphics[scale=0.9]{figuras/clientdone.png}}
\caption{Exemplo com a resposta final do cliente.}
\label{fig:clie}
\end{figure}

\begin{figure}[H]
\centerline{\includegraphics[scale=1]{figuras/servdone.png}}
\caption{Exemplo com a resposta final do servidor, finalizando o \emph{handshake}.}
\label{fig:servvvv}
\end{figure}

Em resumo, o cliente inicia o \emph{handshake} com um \emph{client hello}, o servidor responde com pelo menos três mensagens (\emph{server hello}, seu certificado, \emph{server hello done}). Nessa resposta, o servidor também pode pedir um certificado do cliente, mas esse fato é raro e não é necessário para esse documento. O cliente então encerra o processo e dá abertura a conexão cifrada, ele envia um \emph{client key exchange}, um \emph{change cipher spec} e um \emph{encrypted handshake message}. O servidor confere essas últimas mensagens e responde igualmente com  um \emph{change cipher spec} e um \emph{encrypted handshake message}. Ambas as partes estabelecem assim o fim do \emph{handshake} e o ínício da conexão segura. Caso qualquer etapa do \emph{handshake} falhe, um alerta é enviado pelo servidor.

\begin{figure}[H]
\centerline{\includegraphics[scale=1]{figuras/handshake.png}}
\caption{Exemplo geral de um \emph{handshake}. Nota-se que o \emph{encrypted handshake message} está sendo chamando apenas de \emph{finished}.}
\label{fig:handsssha}
\end{figure}


\section{Formato dos pacotes TLS/SSL}
Para a confecção da ferramenta deste trabalho de conclusão de curso foi preciso um conhecimento detalhado dos pacotes TLS/SSL, pois a ferramenta desenvolvida usa abundantemente desses pacotes e cada um dos bytes de cada pacote da ferramenta são manualmente atribuídos de acordo com as regras de formação de pacotes TLS/SSL~\cite{RFCSSL1}~\cite{RFCSSL2}.

Cada pacote TLS/SSL começa com um byte dizendo se o pacote faz parte do \emph{handshake}, é um alerta, um \emph{change cipher spec} (rever seção anterior) ou um pacote normal com o TLS já em andamento. Logo em seguida há dois bytes com a versão do protocolo usado e mais dois bytes com o tamanho da mensagem.

\begin{table}[H]
\caption{Tipos de pacotes TLS/SSL~\cite{figpacket}.}
\begin{tabular}{|l|l|p{8cm}|}
\hline
Byte(hexadecimal)	&Nome	&Descrição\\
\hline
0x14 	&ChangeCipherSpec	&Indica que as próximas mensagens estarão cifradas.	\\ \hline
0x15 	&Alert				&Um alerta de algo errado durante a execução do protocolo. \\ \hline
0x16 	&Handshake			&Característico de todas as mensagens do \emph{handshake}. \\ \hline
0x17	&Application			&Presente nas mensagens depois que o protocolo já está ativo. \\
\hline
\end{tabular}
\end{table}

Logo em seguida, há um campo detalhando a funcionalidade da mensagem em si, caso ela seja um alerta ou parte do \emph{handshake}. No caso de alertas, há dois bytes especificando se o alerta foi fatal ao uso do protocolo ou só uma precaução e o código do erro que ocorreu. Caso o pacote seja parte do\emph{ handshake}, há um byte que diz qual o tipo da mensagem em si, como pode ser visto na tabela ~\ref{tab:opcode} abaixo.


\begin{table}[H]
\label{tab:opcode}
\caption{Tipos de mensagens durante o \emph{handshake}~\cite{figpacket}.}
\begin{center}
\begin{tabular}{|c|c|}
\hline
Byte(decimal)	&Nome\\
\hline
0 	&HelloRequest \\ \hline
1 	&ClientHello\\ \hline
2 	&ServerHello\\ \hline
11 	&Certificate\\ \hline
12 	&ServerKeyExchange\\ \hline
13 	&CertificateRequest\\ \hline
14 	&ServerHelloDone\\ \hline
15 	&CertificateVerify\\ \hline
16 	&ClientKeyExchange\\ \hline
20 	&EncriptedHandshakeMessage\\
\hline
\end{tabular}
\end{center}
\end{table}

O formato das mensagens com o protocolo em funcionamento são bem simples, como já dito, há um byte para o tipo (\emph{application}) , a versão do protocolo, o tamanho do resto do pacote e os dados cifrados. Já os pacotes referentes ao \emph{handshake} são bem variados mas tendem a manter a estrutura da figura ~\ref{fig:package}.


\begin{figure}[H]
\centerline{\includegraphics[scale=1]{figuras/package.png}}
\caption{Esquema geral de um pacote do protocolo TLS/SSL durante um \emph{handshake}~\cite{figpacket}(adaptada para o português).}
\label{fig:package}
\end{figure}

\section{Diffie \& Hellman}
O Diffie \& Hellman é um método de negociação de chaves, as duas partes envolvidas transmitem parâmetros entre si e deduzem a partir deles uma mesma chave. Um possível atacante observando todos os parâmetros transmitidos não consegue deduzir a mesma chave, o método é computacionalmente seguro. Esse método está implementado dentro de várias \emph{cipher suites} e com várias adaptações disponíveis.

Na confecção da ferramenta associada a esse documento, é usado o protocolo em sua versão básica. Por tal motivo, se torna necessário um entendimento razoável do seu funcionamento. Usando como exemplo um cliente e um servidor, podemos dizer que o protocolo começa com ambos escolhendo um número secreto. O servidor escolhe o número \lq{}a\rq{} e o cliente o número \lq{}b\rq{}, em seguida o servidor escolhe uma raiz primitiva\footnote{Basicamente, uma raíz primitiva módulo \emph{n} é um número que quando elevado a um expoente inteiro gera todos os números daquele espaço \emph{n}, ou seja, todos os números de 1 até \emph{n} podem ser optidos exponenciando a raíz a algum expoente inteiro modulo \emph{n}.} \lq{}g\rq{} e um número primo \lq{}p\rq{}.

De posse desses valores, o servidor envia ao cliente \lq{}A\rq{}, o resultado da seguinte equação:

\begin{equation}
\label{eq1}
A = g^a \bmod p
\end{equation}

O cliente pega o resultado da equação ~\ref{eq1} e eleva a seu número \lq{}b\rq{} módulo \lq{}p\rq{}, assim obtento a chave \lq{}K\rq{}.
\begin{equation}
\label{eq2}
K = A^b \bmod p
\end{equation}
 O cliente então manda para o servidor o resultado \lq{}B\rq{} da seguinte equação:

\begin{equation}
\label{eq3}
B= g^b \bmod p
\end{equation}

Assim, o servidor chega no mesmo valor de chave \lq{}K\rq{} através da equação:
\begin{equation}
\label{eq4}
K= B^a \bmod p
\end{equation}

No final do processo, ambos servidor e cliente possuem a mesma chave e os únicos valores que precisaram ser transmitidos foram \lq{}A\rq{},\rq{}g\rq{},\rq{}p\rq{} e \lq{}B\rq{}. Com apenas esses valores fica computacionalmente inviável a um observador descobrir a chave \lq{}K\rq{}. A figura ~\ref{fig:diffie} ilustra de forma bem simples o método.

\begin{figure}[H]
\centerline{\includegraphics[scale=0.4]{figuras/diffie.png}}
\caption{Diagrama da negociação de chaves usando Diffie \& Hellman~\cite{diffie}. Sendo \lq{}K\rq{} a chave, \lq{}g\rq{} o gerador, \lq{}p\rq{} um número primo e \lq{}a\rq{} e \lq{}b\rq{} números escolhidos aleatóriamente.}
\label{fig:diffie}
\end{figure}
